Today information exchange has become a natural part of the daily routines for parties active in a majority of professions. Such information exchange may range from physically typing information retrieved from an information carrier into some storage means, to exchanging information between entities, often relying on a user interaction from one or more parties participating in the information exchange process.
Exchanging business cards is a well established custom for exchanging personal information between business associates, as well as during different occasions whenever two individuals are making any kind of new acquaintances.
A classical approach to an exchange of business card information, typically following the conventional vCard standard, is that a user receives a paper based business card and manually enters the information printed on the card, such as e.g. telephone number, e-mail and mail address, into his or her User Equipment, such as e.g. a PDA or a cellular telephone. Another way of exchanging business card information is to attach the business card information into an SMS, MMS or an e-mail which is then transmitted between the two parties, or to use a Bluetooth or an Infrared connection for exchanging the business card information.
Today there is, however, few simple ways to update an address book without requiring a tedious number of interactions of sourcing an already established address book of a different format, often requiring adaptation and modification to achieve compatibility.
In addition, there is no way of “leaving this kind of information behind”, enabling other users to easily retrieve the information, or even updated information, at a later occasion.
Manual insertion of business card information into a User Equipment is often regarded to be a time consuming process, with a considerable risk for misspelling. In addition, existing technique used for exchanging business card information is also often considered quite complicated to handle by the ordinary user since commonly known information exchanging procedures often require interactions from both the transmitting and the receiving party.
Another way of exchanging information between users may be provided via the Presence service. Presence service offers an extensive mechanism for customizing a service for information delivery according to the users needs and preferences.
FIG. 1 is a schematic illustration of a Presence System, according to the prior art, which is operating in accordance with well known SIP/IMS standards.
A Watcher 100, i.e. a user provided with a User Equipment enabled to access presence services from a Presence System 101, defined by the entities located within the dotted square, may request for presence information of a Presentity 102, i.e. another user, which has also activated a presence service, enabling authorized Watchers to access information associated with the Presentity 102. The Watcher 100, requesting for presence information of Presentity 102 communicates with the Presence System 101, via an Application Server, or a Presence Server 103.
In response to a request received from Watcher 100, the Presence Server 103 interrogates a Presence XML Document Server (Presence XDMS) 104, in order to determine whether Watcher 100 has been authorized to see the presence information of Presentity 102,
Updated presence Information may be provided to Presence Server 103 from different Presence Sources 105, such as e.g. a Location Server or an Address Book Server. Presence server 103 may accept presence information, which has been published to it, and distribute it to authorized Watchers as notifications.
A Presence System typically also includes a Resource List Server (RLS) 106, which compiles presence subscriptions in lists. These lists are then stored in an RLS XDMS 107, from where they are accessible for the Presence Server 103.
A standard way for a Presentity to publish presence information about oneself is to send a request, typically a SIP PUBLISH request, to a Presence Server, or an XCAP PUT request to a Presence XDMS. Normally the network can also publish presence information for a user, but such a presence delivery mechanism does, however, not involve a performance of an event triggered by the Presentity.
Publishing of presence information may require a lot of effort from the user, including tasks, such as e.g. typing and/or selecting options, all of which may have a restraining effect on the amount of presence information that is actually being published.
One standard way for a user, typically referred to as a Watcher, to add a buddy, typically referred to as a Presentity, to its list of presence enabled buddies is to send a request, typically in the form of an XCAP PUT request, to an RLS XDMS and/or to a Shared XDMS (not shown). The Presence System will then subscribe for information related to the Presentity on behalf of the Watcher, receiving notifications that are then conveyed to the Watcher.
Today there is no straightforward and simple way to automatically add a buddy to the list of presence enabled users via a User Equipment. Methods for adding such information today requires that the address information of each buddy to be added has to be manually entered into the user equipment. Addresses usually are quite long, and, thus, the risk of misspelling may be considerable, which in turn may lead to a less frequently utilization of this type of services, compared to what could have been the case with a more user friendly mechanism for defining the service and/or for executing the service.